home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Columbia Kermit
/
kermit.zip
/
newsgroups
/
misc.19980424-19980901
/
000062_news@newsmaster….columbia.edu _Sun May 10 16:46:21 1998.msg
< prev
next >
Wrap
Internet Message Format
|
2020-01-01
|
3KB
Return-Path: <news@newsmaster.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA11618
for <kermit.misc@watsun.cc.columbia.edu>; Sun, 10 May 1998 16:46:21 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA15560
for kermit.misc@watsun; Sun, 10 May 1998 16:46:20 -0400 (EDT)
Path: news.columbia.edu!panix!nntprelay.mathworks.com!news.voicenet.com!news3.voicenet.com.POSTED!not-for-mail
From: cmosley@voicenet.com (Christopher Mosley)
Subject: Gnu ls and ansi color
Newsgroups: comp.protocols.kermit.misc
X-Newsreader: TIN [version 1.2 PL2]
Lines: 51
Message-ID: <mko51.78$%T6.1215229@news3.voicenet.com>
Date: Sun, 10 May 1998 20:44:02 GMT
NNTP-Posting-Host: omni2.voicenet.com
NNTP-Posting-Date: Sun, 10 May 1998 16:44:02 EST
Xref: news.columbia.edu comp.protocols.kermit.misc:8714
In mskermit Ansi-bbs color behave differently than vt** color.
A dos Ansi image displays different colors when vt** emulation
is used - different from ansi-bbs emulation in mskermit or in dos when
ansi.sys is loaded ( this has nothing to do with the char set being used
(darker/lighter) - the image colors are different even when vt** emulation
uses the "transparent" (dos) char set. It is also independent of the
terminfo or termcap $TERM and is present when strings are simply typed
(cat file) to the screen. That is a correction to a term description
would not correct the problem - I _think_ the problem is with the
underlying properties of the terminal emulation.
The ansi escape sequences gnu "ls" (list program in Gnu file utils) uses,
work properly only under ansi-bbs emulation. I have Gnu "ls" working properly
by using a sh script that uses the apc escape mechanism to temporarily
switch to ansi-bbs emulation before "ls" writes to the screen. This works
fine (the time involved in switching emulations occurs quickly and is not
noticable). Previous output of "ls" under vt** emulation seems to affect
the color of those color strings that come later, and the prompt and all
following output after "ls" is done, retain the color of the last color
output of the "ls" command. This doesn't happen when ansi-bbs emulation
is used.
Gnu "ls" was presumably written to be used with vt terminal/emulation or
something similar and two of the default term types assumed by the "ls"
configuration utility ("dircolors") _are_ vt100 and xterm? I know nothing
of ansi or vt standards?/conventions? (I don't think it would be a formal
standard, afterall a vt100 is not really a color terminal) and am wondering
why this _apparent_ discrepancy exists.
Thanks
Christopher Mosley